This invention relates to a technique of setting up a disaster recovery system through cooperation between a database server and a storage system.
In recent years, information systems have become the foundation of many businesses, and their importance is ever increasing. This expands the impact of system shutdown due to a disaster or the like to a significant degree. In banking business, for example, the system shutdown could cause a loss of nearly several million dollars an hour. It is against this background that disaster recovery (DR) is attracting attention, which makes an information system quickly recover from a disaster for continuation of the service by keeping a backup on a remote site.
Service application data is stored in a database (DB), and it is imperative to restore the whole DB from a disaster without losing any piece of the data. Also, on a day-to-day basis, the data backup has to be carried out continuously while affecting the service as little as possible. Furthermore, the thus obtained backup has to be stored on a remote site that is located several hundreds to several thousands km away in anticipation of an earthquake or other disasters that affect a wide area.
As disclosed in JP 2006-4147 A, “log application” is a known disaster recovery technology in which data update history information (including a log) of the primary site is copied to the remote site (hereinafter, referred to as “remote copy”) and the duplicated log is applied to restore data of the primary site on the remote site.
A DR system utilizing log application (hereinafter, referred to as “log-based DR system”) makes sure that, when the log of the primary site is updated, the updated log is copied to the remote site before proceeding with processing of the primary site (hereinafter, referred to as “synchronous copy”). In addition, JP 11-85408 A discloses a remote copy technology that copies data between separate storage controllers without an intervening database server.
The log-based DR system copies, to the remote site, in advance, data that is stored on the primary site as initial settings (hereinafter, referred to as “initial copy”) and, after the initial copy is finished, copies only the log through synchronous copy. The DB is restored by applying a log that is copied through synchronous copy after the initial copy, and data of the primary site is thus replicated on the remote site. Initial copy is carried out by means of a recording medium or a remote copy function of a storage system. In an example of the initial copy method that utilizes the remote copy function as disclosed in JP 2002-297455 A, data stored in an area to be updated is transferred to a copy destination storage system when a copy source storage system is updated.
According to this method, a primary site storage system from which data is copied has to be quiescent while the initial copy is being executed. In a storage system that is in a quiescent state, updating data stored in the storage system is prohibited. Online processing therefore has to be put off until the initial copy is completed. When the size of data to be copied in the initial copy is large, it takes considerable time to finish the initial copy and the start of online processing on the primary site is delayed.
A DR system may have a local mirror on the primary site, so that one storage system is used for online processing and the other serves as a copy source storage system in initial copy. Duplicating a DB in this manner makes it possible to execute online processing of the primary site in parallel with initial copy processing.
However, the start of log application on the remote site is delayed significantly when the initial copy takes very long. A substantial delay in start of log application in a log-based DR system, which employs ring buffer logging, causes a problem called wrap round in which the log of the remote site is overwritten by online processing of the primary site. Applying the remote site log in this state creates data inconsistency.